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ABSTRACT 

An evaluation of a prototyped user interface is best supported by a simulation of the system. A 
simulation allows for dynamic evaluation of the interface rather than just a static evaluation of the 
screen’s appearance. This allows potential users to evaluate both the look (in terms of the screen 
layout, color, objects, etc.) and feel (in terms of operations and actions which need to be per- 
formed) of a system’s interface. Because of the need to provide dynamic evaluation of an interface, 
there must be support for producing active simulations. The high-fidelity training simulators are 
delivered too late to be effectively used in prototyping the displays. Therefore, it is important to 
build a low fidelity simulator, so that the iterative cycle of refining the human computer interface 
based upon a user’s interactions can proceed early in software development. 

INTRODUCTION 

The Crew Systems Engineering Branch of the Mission Operations Laboratory of NAS A Marshall 
Space Flight Center was interested in a dynamic Human Computer Interface Prototyping Envi- 
ronment for the International Space Station Alpha’s on-board payload displays. On the Space 
Station new payloads will be added to the on-board complement of payloads in ninety day 
increments. Although a payload starts its development and integration processes from two to four 
years before launch, an increment’s set of new payloads’ displays are due every ninety days. Thus, 
this drives the need for an efficient and effective prototyping process. The functional components 
of a dynamic prototyping environment in which the process of rapid prototyping can be carried out 
have been investigated. 

Most Graphical User Interface toolkits allow designers to develop graphical displays with little or 
no programming, however in order to provide dynamic simulation of an interface more effort is 
required. Most tools provide an Application Programmer’s Interface (API) which allows the de- 
signer to write callback routines to interface with databases, library calls, processes, and 
equipment. These callbacks can also be used to interface with a simulator for purposes of 
evaluation. However, utilizing these features assumes programming language knowledge and 
some knowledge of networking. Interface designers may not have this level of expertise and 
therefore need to be provided with a friendlier method of producing simulations to drive the 
interface. 
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A rapid prototyping environment has been developed (Moore, 1993) which allows for rapid pro- 
totyping and evaluation of graphical displays. The components of this environment include: a 
graphical user interface development toolkit, a simulator tool, a dynamic interface between the 
interface and the simulator, and an embedded evaluation tool. The purpose of this environment is 
to support the process of rapid prototyping, so it is important that the tools included within the 
environment provide the needed functionality, but also be easy to use. 

This paper describes two options for simulation within the dynamic prototyping environment: 
petri nets and rule-based simulation. The petri net system which has been evaluated, PERCNET, 
is designed to be used as a knowledge-based graphical simulation environment for modeling and 
analyzing human-machine tasks. With PERCNET, task models (i.e., simulations) are developed 
using modified petri nets. The rule based system which has been developed is a CLIPS based 
system with an X windows interface for running the simulations. CLIPS executes in a non- 
procedural fashion making it ideal for representing random and concurrent events required by the 
simulation. It’s C language-based design allows external communication to be programmed di- 
rectly into the model. In order to compare the two approaches for simulation, a prototype of a user 
interface has been developed within the dynamic prototyping environment with both simulation 
architectures. This paper compares the two systems based upon usability, functionality, and 
performance. 

ARCHITECTURE OF THE DYNAMIC PROTOTYPING ENVIRONMENT 

There are four components of the Human Computer Interface (HCI) Prototyping Environment: (1) 
a Graphical User Interface (GUI) development tool, (2) a simulator development tool, (3) a dy- 
namic, interactive interface between the GUI and the simulator, (4) an embedded evaluation tool. 
The GUI tool allows the designer to dynamically develop graphical displays through direct 
manipulation. The simulator development tool allows the functionality of the system to be im- 
plemented and will act as driver for the displays. The dynamic, interactive interface will handle 
communication between the GUI runtime environment and the simulation environment. The em- 
bedded evaluation tool will collect data while the user is interacting with the system and will 
evaluate the adequacy of an interface based on a user’s performance. The architecture of the 
environment is shown in figure 1. 



Figure 1 - HCI Prototyping Environment Architecture 






Interface Development Tool 


The Graphical User Interface (GUI) tool for the prototyping environment will allow the designer 
to create the display through direct manipulation. The GUI tool allows the designer to dynami- 
cally create static and dynamic objects, windows, menus, and boxes. The tool also allows objects 
created to be linked to a data source. During execution, the interface objects send and receive data 
and commands to the simulator by way of the data server. The user interface objects and their 
associated data access description are defined independent of the actual source of data. This first 
allows the development of the interface and the simulator to occur concurrently. Second, an in- 
terface developed with the GUI tool can later be connected to a high fidelity simulator and then to 
the actual flight software. 

Simulator Development Tool 

The simulator development tool provides the capability to develop a low fidelity simulation of a 
system or process. The development of a simulation has two important functions. First, the sim- 
ulation helps the designer identify and define basic system requirements. Second, potential users 
can evaluate both the look (in terms of the screen layout, color, objects, etc.) and feel ( in terms of 
operations and actions which need to be performed) of a system. The simulator provides realistic 
feedback to the interface based on user inputs. 

Dynamic, Interactive Interface 

This interface will handle communication between the GUI prototyping tool and the simulation 
tool during execution. The interface is a server which has been developed using the GUI’s Appli- 
cation Programmer’s Interface. Messages and commands can be sent and received both ways 
between the interface, the simulator and the server. The server also services requests from the 
embedded evaluation process, providing information as to which actions the user has taken and 
which events and activities have fired. 

Embedded Evaluation Tool 

An important aspect of the prototyping process is the .ability to evaluate the adequacy of the de- 
veloped graphical user interfaces. The embedded evaluation tool communicates with the server to 
receive information on the interaction between the user and the system. The types of data col- 
lected include user actions, simulator events and activities, and the times associated with these 
items. The collected data is analyzed to determine task correctness, task completion times, error 
counts, and user response times. The data is then analyzed to provide feedback as to which fea- 
tures of the interface the user had problems with and therefore need to be redesigned. 

An Example: The Automobile Prototype 

In order to assess the architecture described above a system was chosen to be prototyped in the 
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The driver (or user) monitors and controls the automobile’s performance using pedals, levers, 
gauges, and a steering wheel. The dashboard and controls arc die user interface and the engine is 
the main part of the system. Mapping the automobile system to the simulation architecture calls 
for a model of the dashboard and driver controls and a separate model of the engine. Figure 2 
demonstrates how an automobile system could be mapped into the architecture described. The 
main component of the automobile is the engine which responds to inputs from the driver (e.g. the 
driver shifts gears or presses the accelerator pedal) and factors in the effects of the environment 
(e.g. climbing a hill causes a decrease in the speed of the car). The driver changes inputs to obtain 
desired performance results. If the car slows down climbing a hill, pressing the accelerator closer 
to the floorboard will counteract the effects of the hill. 
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Figure 2 - Automobile Prototype 

The dashboard and controls have been modeled using Sammi, a graphical user interface develop- 
ment tool developed by Kinesix. Two options have been investigated for simulation: petri nets and 
rules. Petri nets provide a graphical model of concurrent systems. The petri net system which has 
been used is PERCNET, developed by Perceptronics. PERCNET is designed to be used as a 
knowledge-based graphical simulation environment for modeling and analyzing human-machine 
tasks. With PERCNET, task models are developed using modified petri nets, a combination of 
petri nets, frames, and rules. The rule based system which has been used is CLIPS, a rule based 
language primarily used for the design of expert systems, developed by NASA. CLIPS executes 
in a non-procedural fashion making it ideal for representing random and concurrent events. The 
automobile system has been prototyped using both the petri net and rule-based systems as simu- 
lators and comparisons have been made based upon functionality, usability, and performance. 

SIMULATION IN THE DYNAMIC PROTOTYPING ENVIRONMENT 

Because of the need to provide dynamic evaluation of an interface rather than just static evalua- 
tion, there must be support provided for producing active simulation. Most GUIs, including 
Sammi, provide some sort of Application Programmer’s Interface (API) which allow the devel- 
oper to write call back routines which interface with databases, library calls, other processes and 
equipment. We would like to provide a means of building a low fidelity simulation of the system 
to drive the interface which does not require programming. 


Basic simulation requirements include the ability to model events and activities, both sequentially 
and concurrently. The system should provide the ability to create submodels within the main 
model. The simulator clock must be linked to the system clock, and support should be provided 
for the creation of temporal events. The process must be able to communicate with UNIX pro- 
cesses using the TCP/IP protocol. Real time communication must also be provided to allow the 
tool to communicate with the GUI tool on a separate platform via Ethernet. The ability for two- 
way asynchronous communication between the runtime versions of the interface and the simulator 
must be provided. The simulator must be capable of receiving data from the GUI tool to dynam- 
ically control temporal events, to modify the values of variables, and trigger events and activities. 
The ability to specify and send commands, data, and alarms to the GUI tool must also be provided. 
A simulator director should be able to send commands (e.g„ start simulation, trigger scenario 
event, etc.) to the simulator from a monitoring station. An interface should be provided in order to 
bind interface objects to simulation objects in order to set the values of variables, trigger events or 
activities, and set temporal variables. 

Simulation Using Petri Nets 


PERCNET is a very powerful systems analysis software package designed by Perceptronics, Inc. 
It provides an easy-to-use, graphical interface which allows users to quickly lay out a petri net 
model of the system. PERCNET uses "modified" petri nets, which allow each state to describe 
pre-conditions for state transitions, modify global variables, perform function calls and maintain a 
global simulation time. 

Pictorially, Petri nets show systems of activities and events. Ovals represent activities which de- 
scribe actions performed by the system. Activities are joined by events, represented by vertical 
bars, that occur during execution. Events are associated with user actions and environmental 
conditions. Execution is shown by tokens propagating through the system. Flow of control passes 
from activities to events. Before an event can fire all incoming arcs must have tokens. When this 
occurs, the event places tokens on all outgoing arcs passing control to activities. The behavior that 
an event exhibits during execution is dependant on the data contained in its frame. Frames record 
data related to each activity and event. Event frames may contain rules and functions. Activity 
frames allow the designer to specify a time to be associated with each activity. Figure 3 shows the 
top-level petri net of the automobile simulator. 



Figure 3 - Top-Level Petri Net of the Automobile Simulator 




The starter is the component that is activated by the turning of the key. Before the starter can begin 
working, however, the key should be turned on, the driver must be wearing his/her seat belt, the 
car must be in neutral and the battery must have a sufficient charge to start the starter. When all 
three pre-conditions are true, the starter is activated and control advances to the right in the Petri 
net. Once the starter has been activated, it must do its part to start the automobile. The starter 
allows electricity to flow into the distributor where it is channeled into the spark plugs. As long as 
the starter is functioning, the distributor and spark plugs are activated. Finally, as long as the spark 
plu gs and distributor are working properly and there is gasoline, the spark from the spark plugs 
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In this project, CLIPS has been extended to include communication capabilities. Two sockets 
have been provided for reading from and writing to the server. C functions have been developed 
to eliminate redundant information from the messages passed to the server. Another improvement 
compiled into the CLIPS executable has been a control process that allows a user to start, stop and 
quit CLIPS execution through a graphical interface. 


The project also demonstrates some programming techniques used in CLIPS to support the 
simulation. A global simulation time should be maintained and a mechanism for keeping simula- 
tion execution time has been demonstrated. Another important feature that makes use of the timer 



CLIPS was written in the C programming language and is completely compatible and extendible 
with C functions. Knowing C in advance can significantly lessen the learning curve. Many of the 
"non-C" features of CLIPS resemble LISP. CLIPS has been a tremendous surprise to work with. 
A basic proficiency with CLIPS may be gained quickly and one can learn to do very useful things 
with the language. Writing the rules for the simulation was actually the easiest part of the project. 
As proficiency with the language developed, more advanced features provided tremendous 
possibilities. The manuals present the language in a very easy to read format, contained extensive 
reference sections and sample code. Furthermore, the manuals outline how CLIPS may be easily 
extended to include C (and other) functions written by programmers. 

Functionality 


As this project began, PERCNET was a closed package, that is, there was no provision for com- 
municating with other applications. NASA contracted Perceptronics to modify PERCNET to 
allow for such a feature. The final result was a revision of PERCNET which would allow com- 
munication with other applications through the use of sockets. Applications are allowed to request 
that global variables be retrieved and/or modified. PERCNET essentially opened it’s blackboard 
(i.e., global data store) to other applications. The other application in this case being the server. 

After several functions were added to CLIPS (see descriptions in previous sections), the CLIPS 
system performed the same functions as the Petri Net simulator. If a new system is prototyped, the 
only changes which would be needed are to the knowledge base. The communication link devel- 
oped for the Sammi-CLIPS architecture uses the blackboard paradigm to improve modularity, 
flexibility, and efficiency. This form of data management stores all information in a central loca- 
tion (the blackboard), and processes communicate by posting and retrieving information from the 
blackboard. The server manages the blackboard, allowing applications to retrieve current values 
from the board and to request that a value be changed. The server accepts write requests from 
valid sources and changes values. The comparison of the two architectures goes much further than 
comparing the two simulation designs. The design of the communication link significantly affects 
the flexibility and performance of the architecture. 

Performance 

The performance within the Petri Net architecture was not acceptable for real-time interface 
simulation. Interfaces running within this architecture exhibit a very slow response rate to user 
actions when PERCNET is executing within its subnets. The PERCNET execution is also using 
excessive amounts of swap space and memory which also affect the refreshing of displays. 

Early analysis attempted to find the exact cause of the poor performance; however, only limited 
work could be done without access to PERCNET’s source code. Since PERCNET’s code was 
unavailable, we could only speculate about what was actually happening to cause the slow 
responses. It was determined that the cause of much of the problem was that PERCNET was 
trying to do too much. In the PERCNET simulation architecture, PERCNET is actually the data 
server for the environment. The global blackboard is maintained within PERCNET. The server 
only provides a mechanism for passing information between PERCNET and other applications. 
The server is connected to PERCNET by a socket and the server is actually on the "client" end of 
the connection-oriented socket. The server establishes connections with PERCNET and Sammi 
and then alternately receives information from each. Any data or commands received from Sammi 
are passed immediately to PERCNET. Commands from PERCNET for Sammi are passed 




Lastly, the method provided for sending variables to the server was terribly inefficient. When a 
calculation was performed in the simulation model for a variable that was needed by the interface, 
that variable was passed to the server whether or not it’s value had changed from the previous 
iteration. No mechanism was provided for restricting the number of redundant values passed 
across the communication link. As a result, PERCNET passed every value back to the server when 
only a few had actually changed. 

Each of these limitations was addressed in the design of the server and blackboard in the rule- 
based architecture. The server program may be divided into three portions: blackboard manage- 
ment, Sammi routines, CLIPS routines. The Sammi and CLIPS routines are provided to 
communicate with the respective applications. These routines map data into a special "blackboard 
entry" form and pass the data to the blackboard management routines. The blackboard routines 
also return information to the Sammi and CLIPS routines for routing back to the applications. The 
blackboard management routines require that each application (many more applications may be 
supported) register itself initially. Applications are assigned application identification numbers 
which are used for all subsequent transactions. This application number allows the blackboard to 
closely monitor which variable values each application needs to see. It also provides a mechanism 
for installing a priority scheme for updates. 

The overwhelming advantage of the CLIPS and blackboard combination is the flexibility and po- 
tential they provide. Features are provided that allow modifications which can affect performance. 
The ability to tune the performance has allowed the simulation architecture to be tailored to spe- 
cific running conditions (e.g., machine limitations, network traffic and complexity of the interface 
being simulated). Several parameters may be modified to alter performance. Tuning tests have 
improved performance. More detailed performance testing is planned to verify the results. 

CONCLUSION 

The goal of the architecture has been to provide simulation of user interfaces so that they may be 
designed and evaluated quickly. An important portion of the dynamic prototyping architecture is 
therefore the simulator. Ease-of-use is very important, but performance is critical. The Petri Net 
architecture’s ease-of-use is currently it’s only advantage over the Rule-Based architecture. The 
Rule-Based design overcomes this with power and flexibility. Work currently in progress include 
a detailed analysis of the performance of the communication link and a design of a graphical 
interface to CLIPS. 
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